Skip to content
This repository has been archived by the owner on May 2, 2023. It is now read-only.

Arm64 Support #830

Closed
wants to merge 3 commits into from
Closed

Arm64 Support #830

wants to merge 3 commits into from

Conversation

jonstelly
Copy link

@jonstelly jonstelly commented Feb 6, 2020 •
edited
Loading

Basic working zookeeper and kafka docker images for arm64 platform. Resolves #718

There are still a handful of TODOs before this is ready to merge but I'm hoping to get some feedback on the basic changes and if this looks like a reasonable direction.

I've got docker images published at:

kymeric/cp-base
kymeric/cp-zookeeper
kymeric/cp-kafka

Testing:
I've run the following slightly-modified getting started commands on my raspberry pi 4 and everything works as expected. I'll be testing more thoroughly over the next few weeks.

commands:

echo "Starting zookeeper and kafka for $(hostname)";
docker run -d  --name=zookeeper -e ZOOKEEPER_CLIENT_PORT=2181 -p 2181:2181 kymeric/cp-zookeeper
docker run -d --name=kafka -e KAFKA_ZOOKEEPER_CONNECT=$(hostname):2181 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://$(hostname):9092 -p 9092:9092 -e KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR=1 kymeric/cp-kafka
echo "Sleeping for 20 seconds to let broker come up..."
sleep 20
echo "Creating topic: 'foo'"
docker run --rm "kymeric/cp-kafka:latest" kafka-topics --create --topic foo --partitions 1 --replication-factor 1 --if-not-exists --zookeeper $(hostname):2181
echo "Describing topic: 'foo'"
docker run --rm "kymeric/cp-kafka:latest" kafka-topics --describe --topic foo --zookeeper $(hostname):2181
echo "Producing 42 messages for: 'foo'"
docker run --rm "kymeric/cp-kafka:latest" bash -c "seq 42 | kafka-console-producer --request-required-acks 1 --broker-list $(hostname):9092 --topic foo && echo 'Produced 42 messages.'"
echo "Killing zookeeper and kafka"
docker rm -f zookeeper kafka

os:

ubuntu@pi4b:~$ uname -a
Linux pi4b 5.3.0-1017-raspi2 #19-Ubuntu SMP Thu Jan 16 18:25:50 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@pi4b:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 19.10
Release:        19.10
Codename:       eoan

output:

Starting zookeeper and kafka for pi4b
03bb21c35d349e0a8dd5d63420aa6e0781b6e110fa8047a6b229b888836dd9b6
8b7bb902fd6076ff2d9a5068c35bef96bf86cec95d89e427e9d4f4bf95c4499e
Sleeping for 20 seconds to let broker come up...
Creating topic: 'foo'
Created topic foo.
Describing topic: 'foo'
Topic:foo       PartitionCount:1        ReplicationFactor:1     Configs:
        Topic: foo      Partition: 0    Leader: 1001    Replicas: 1001  Isr: 1001
producing 42 messages to: 'foo'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Produced 42 messages.
Killing zookeeper and kafka
zookeeper
kafka

Comments welcome and appreciated.

Changes:

  • Initial arm64 support
  • Switch from debian:jessie to debbian:stable (Jessie not available for arm64`)
  • Switch to openjdk-11, zulu not available for arm64?
  • Parameterize Docker 'FROM' to use $REPOSITORY, default to 'confluentinc', pass to docker as build-arg from build-debian script

Build:

  • Ubuntu >= 18.04? (I was using 19.10)
  • docker >= 19.03.5
  • apt install qemu-user qemu-user-static make maven
  • enable experimental on docker daemon and client (for buildx)
  • docker buildx create --name mp --platform=linux/arm32,linux/arm64,linux/amd64 --use
  • docker buildx inspect mp --bootstrap
  • make build-debian REPOSITORY=kymeric COMPONENTS="base zookeeper kafka"

TODO:

  • Build/Test other components: I'm only working with zookeeper and kafka images. I can easily build and publish these images but I will need help testing them
  • Remove maven repository from pom.xml? (I imagine this shouldn't be needed but I got an error without it and the first issue I found mentioned this fix)
  • I commented out the "rpm" type in the Makefile so I could focus on debian packages. Need to check/verify all centos packages build and are cross-platform
  • debian/base adds the confluent APT repository with [arch=amd64], but the packages seem to be architecture agnostic. I'm not an APT expert, can we just remove [arch=amd64]? Leaving it for now for some discussion with people who would know better
  • Zulu cleanup? Still see the zulu version variable in a few places
  • Tag images with version label - Need to switch from docker tag ... to some docker manifest create... push commands, comments in build-debian.
  • Add arm32 images? I don't need these since I'm on arm64, I'm unsure if there's much demand for kafka on arm32. But it would/should be easy to just add the arm32 platform

@jonstelly
Update from debian:jessie -> debian:stable
ba67890
@jonstelly
Add maven repository
7af604d
@jonstelly
ARM64 Builds
6abdb0f 
- Initial arm64 support
- Switch to openjdk-11, zulu not available for arm64?
- Parameterize Docker 'FROM' to use $REPOSITORY, default to 'confluentinc', pass to docker as build-arg from build-debian script

Steps:
- Ubuntu >= 18.04? (I was using 19.10)
- docker >= 19.03.5
- `apt install qemu-user qemu-user-static make maven`
- enable experimental on docker daemon and client (for buildx)
- `docker buildx create --name mp --platform=linux/arm32,linux/arm64,linux/amd64 --use`
- `docker buildx inspect mp --bootstrap`
- `make build-debian REPOSITORY=kymeric COMPONENTS="base zookeeper kafka"`

-TODO: I commented out the "rpm" type in the Makefile so I could focus on debian packages.  Need to check/verify all centos packages build and are cross-platform
- TODO: debian/base adds the confluent APT repository with [arch=amd64], but the packages seem to be architecture agnostic.  I'm not an APT expert, can we just remove [arch=amd64]?  Leaving it for now for some discussion with people who would know better
- TODO: Zulu cleanup?  Still see the zulu version variable in a few places
- TODO: Tag images with version label - Need to switch from `docker tag ...` to some `docker manifest create... push` commands, comments in build-debian.
@ghost
Copy link

ghost commented Feb 6, 2020

It looks like @jonstelly hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement here.

Once you've signed reply with [clabot:check] to prove it.

Appreciation of efforts,

clabot

@jonstelly
Copy link
Author

[clabot:check]

@ghost
Copy link

ghost commented Feb 6, 2020

@confluentinc It looks like @jonstelly just signed our Contributor License Agreement. 👍

Always at your service,

clabot

@jonstelly jonstelly mentioned this pull request Feb 6, 2020
Closed
@jonstelly jonstelly changed the title Feature/arm64 Arm64 Support Feb 6, 2020
@jonstelly
Copy link
Author

I've also got the base zookeeper image building for a handful of different architectures (since that's what the kafka helm chart uses): 31z4/zookeeper-docker#90

As noted in that PR, it's now possible to use helm to deploy kafka with zookeeper to kubernetes on arm64, amd64... Is there interest in widening the supported platforms to some of the additional zookeeper platforms? I've only got amd64 and arm64 for testing so would need some additional help for testing those other platforms.

@dchuyko
Copy link

dchuyko commented Feb 10, 2020

Just in case, Liberica JDK is available for arm64 (and x86 of course) with free security updates, and customers have an option to get extra support for exactly the same binary.

@jonstelly
Copy link
Author

jonstelly commented Feb 10, 2020 •
edited
Loading

I haven't been a Java guy for a while so my read on the JDK/JRE landscape is extremely basic. So we've got Liberica, Zulu, the OpenJDK, AdoptOpenJDK.

I do see that Zulu has images available for arm32, arm64 and amd64 but they didn't seem to be in their debian repository and they only provide docker images for amd64.

The switch to openjdk was more of a proof-of-concept because it made building for all platforms easier, but it feels like the right thing to do may be to just switch the dockerfile to download the Zulu JDK archive and extract it?

Alternatively, the changes I made for the base/library zookeeper image linked above was to use adoptopenjdk:8u232-b09-jre-hotspot as a base image so we could do that here too? I'm not sure if any of the confluent docker images need the full JDK instead of just the JRE, but if that's only a few we could even split cp-base into cp-base-jre and cp-base-jdk. The image size difference is ~100-140MB per platform and that could be worth the split.

Happy to get some suggestions/guidance here.

@alanreynosov
Copy link

So, this is going to be merged soon?, are waiting to build their own ARM64 images?

@jonstelly
Copy link
Author

I haven't heard back from the maintainers and my environments have changed to where I'm not using Kafka on ARM64 anymore so this isn't a priority for me, but... I would still like to get this merged so I'm happy to finish this up if I can get some guidance from Confluent/maintainers.

I think the only open question here would be about the JDK. It looks like Zulu now builds openjdk v8 for arm64 but I'm not sure if they publish the arm64 package to their APT repo. I can set things back up and test that but I'd rather hear from a maintainer that it's something they'd be willing to merge before I spend more time on it.

@ottaviohartman ottaviohartman mentioned this pull request Jan 5, 2021
Closed
@andrewegel
Copy link
Contributor

First off: Thank you for taking the time to contribute changes to this project, but unfortunately we are unable to accept the changes:

  • This is a "deprecated" project - No more enhancements will be going into it. We may do a couple of older CP docker images releases from it at a future point in time, or to address security issues in the docker image, but new features such as new platform support for older CP releases are not something we're going to consider.
  • The changes as proposed change the underlying OS version (From jessie to stable), this breaks Confluent's SemVer contact in terms of versioning of our Docker Images.

To the first point, you can follow confluentinc/common-docker#117 until such a time when Confluent will adopt ARM64 platform support into the cp-* images Confluent Inc distributes on Docker Hub.

Closing since we're not planning on ARM support in this deprecated repo.

@andrewegel andrewegel closed this Mar 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Docker images don't work on ARM64
4 participants
@jonstelly @dchuyko @alanreynosov @andrewegel